Scoped memory areas are areas of memory suitable for the allocation and deallocation of objects without some of the disadvantages of garbage collected heaps. A software thread can enter a scoped memory area and all object allocations by the thread will then be made within the scoped memory area. The thread can also enter multiple scoped memory areas in a nested fashion. For example, the thread can enter a second scoped memory area which becomes the default allocation area. Scoped memory areas are organised in a scope graph with each scoped memory area having a parent being the previously entered scoped memory area. A first scoped memory area has a primordial scoped memory area as its parent.
A thread count is maintained for each scoped memory area of a number of active threads in the area. The thread count coupled with the scope graph indicates when a scoped memory area, including any objects allocated in the scoped memory area, is discardable. For example a scoped memory area may be discardable when an associated thread count is decremented from one to zero and the scoped memory area is not a parent for any other scoped memory area. In this way, scoped memory areas offer alternative allocation spaces for objects in an otherwise garbage collected object oriented environment, such as Java (Java is a registered Trademark of Sun Microsystems). The use of such scoped memory areas can address the problem of delays in application execution caused by garbage collection algorithms since all objects in scoped memory areas become discardable at the same time defined in terms of thread usage of the memory area and the organisation of a scope graph.
A first object in a first scoped memory area can reference a second object in a second scoped memory area. However, since individual scoped memory areas can become completely discardable it is necessary to enforce strict rules regarding valid and invalid references between objects in different scoped memory areas. These rules are necessary to guarantee that a parent scoped memory area has a lifetime that is at least that of its child scoped memory areas so that objects in descendant memory areas can reliably reference objects in ancestor memory areas. In this way, dangling references can be avoided. This is described in “Efficient Memory-Reference Checks for Real-time Java” (Corsaro and Cytron, ACM SIGPLAN Volume 38, Issue 7 Jul. 2003).
One such rule is that a scoped memory area has at most one parent. This is known as the “single parent rule”. The single parent rule provides that the order of entry into scoped memory areas by different threads is always the same because the order of entry of threads into scoped memory areas defines the structure of the scoped memory areas in the scope graph. Further, a source object allocated in a source scoped memory area can only reference target objects in the same or ancestral scoped memory areas. An ancestral scoped memory area is a memory area which is entered by a thread before the source scoped memory area. The source scoped memory area is said to have inner scope with respect to that of the target object. This criterion ensures that the source object will always be de-allocated before the target object. Attempts to create references which do not satisfy the criterion must fail according to the Real-Time Specification for Java (Bollella et al, Addison-Wesley, 2000). Thus the criterion must be checked in an efficient manner whenever a new reference to a target object is created.
One way to determine whether this criterion is satisfied for the creation of a reference between objects is to iterate through scoped memory areas in a scope graph. Iteration starts at the source scoped memory area and progresses through each parent scoped memory area checking for the target scoped memory area. If the target scoped memory area is encountered within the scope graph during the iterations then it can be concluded that the criterion is satisfied because the target area is an ancestor of the source area. If the iterations reach the primordial scoped memory area (the “root” of the scope graph) then it can be concluded that the criterion is not satisfied because the target scoped memory area is not an ancestor of the source scoped memory area.
An alternative approach is to determine an index of the distance between the scoped memory area of the target object and the primordial scoped memory area. This distance can be considered to be a “depth” of the target scoped memory area. Additionally, an index of the distance between the scoped memory area of the source object and the primordial scoped memory area can be determined as a “depth” of the source scope. The term depth here is used to indicate that scoped memory areas exist at levels which are some distance from the primordial scoped memory area. Deeper scoped memory areas are located at a level in the scope graph which is further from the primordial scoped memory area. A comparison of these indices of depth will determine whether the target scoped memory area is an ancestor of the source scoped memory area because descendent areas will always be deeper (further from the primordial scoped memory area) than ancestor areas. Thus, if the source scoped memory area is deeper than the target scoped memory area then the criterion is satisfied and a reference can be created.
While these approaches may be effective in applying the criterion for the creation of new references, they involve time consuming iterations through a scope graph at the point of reference creation. These iterations are required either to scan the entire scope graph for the target scoped memory area, or to determine the depth indices.
Thus it would be advantageous to determine whether the rule that a source object allocated in a source scoped memory area can only reference target objects in ancestral scoped memory areas is satisfied without requiring undesirably high processing overhead due to iterations through a scope graph.